Can't comment on Graphics API stuff, but looks good otherwise.

AnimatedModelTests camera nudged for deterministic SwiftShader rendering

I've seen the change related to that, shouldn't we document this ? Do you know where it comes from, what users might want to watch out for when falling in the same issue ?

You've also introduced a submodule to the repo, shouldn't we mention this in the readme's instructions ?

AnimatedModelTests camera nudged for deterministic SwiftShader rendering

I've seen the change related to that, shouldn't we document this ? Do you know where it comes from, what users might want to watch out for when falling in the same issue ?

It's a minor difference when rendering with SwiftShader:

• always the same 1 pixel sometime background sometime mesh, probably with something very close to 50% coverage
• happening on same computer (I just ran it 10 times, it failed 3 times)
  I am not sure if SwiftShader is supposed to be deterministic, but I had no other issue, except on this very specific test on that very specific pixel.
  I tried to adjust a few settings (force thread count, etc.) but it didn't fix it.
  It was a bit disappointing but it's still much better than anything we had before (GPU/driver-specific gold image, no proper gold image unless ran once for a developer on a random PC on a 100% working commit, etc.)

Anyway, you're right, I should probably write it down somewhere for people writing tests.

You've also introduced a submodule to the repo, shouldn't we mention this in the readme's instructions ?

Good point, will do!
Esp. since it deserves some explanation: the idea is to do dependency building as a github workflow so that it's easy to reproduce and control the dev environment (a bit similar to using a docker).
Do you think it's a good idea?
(note: it's not set in stone, we could always change our approach later -- it's still a much better starting point than me building it on an undocumented computer with specific version of compilers)

As usual, thanks for the feedbacks!

Quick addition on why I used a submodule rather than on main repo:

Using github workflow, if you want to use a workflow_dispatch to trigger it by clicking a button (which I think is the only option, we can't make it build again every commit), it will only appear on Actions list to click if it's merged on the main branch (!)

Let's say, you are working on a feature branch and need a new dll, you can't do it by adding a workflow on Stride repo in that branch as you can't run this workflow (unless you do it in master).

It's a bit unfortunate but I couldn't figure out a workaround, and that's why I came up with a separate deps repository where we can more easily build/push the deps on master and build them (this can be done in a branch once the workflow is in master) then merge the branch with the dll.

We can still give it a try on Stride directly to avoid submodules.
Or use NuGet packages to distribute/consume.

However, we will likely need submodule for the SPIR-V branch anyway (unless I also copy/subtree it on our repo), as it needs CppNet8, SpirvHeaders and SpirvRegistry.

What do you think, should we avoid them? or embrace them?
I had horror stories with them when we were using them very actively for some sub-part of our engine (i.e. we used them for all large binaries in the past before git LFS). But in this case, those submodules won't change much and/or are external, so I thought it would be manageable.

Actually, let me try to put everything back on main repo
I will use a workflow that will generate a nuget package
I suppose it's not that big of a deal if we need to just commit that workflow (or at least a skeleton of it) on master before we can use it in branches.

I had horror stories with them when we were using them very actively for some sub-part of our engine

I remember that. I still have PTSD 😅.

I will use a workflow that will generate a nuget package

That seems more manageable if you can make it work.

Side note: after merging #3115, I think we still have some workflows that have a trigger on push (while filtering some paths). Now that the main CI is triggered all the time, we should remove it from sub-workflows. Except maybe buid-android until it is fixed.